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Reply to Office Action of March 24, 2009 

REMARKS 

In response to the Office Action mailed March 24, 2009, the new Assignee (Nuance 
Communications, Inc.) respectfully requests reconsideration. Claims 1-10 and 30-39 (including 
independent claims 1, 30 and 39) were previously pending in this application. In this amendment, 
claims 1, 2, 7, 8, 30, 31, 35-37 and 39 have been amended and no claims have been added or 
canceled. As a result, claims 1-10 and 30-39 remain pending for examination with claims 1, 30 and 
39 being independent. No new matter has been added. 

I Rejections Under 35 U.S.C. S103 

It is noted that prior counsel requested a constructive suggestion for a claim amendment in 
accordance with MPEP §706(11), and that the Examiner provided such a suggestion. The 
Examiner's efforts to advance the prosecution of the application are appreciated. However, the 
suggestion has not been adopted, as the claims as presented are believed to be patentable. 

H. Rejections Under 35 U.S.C. §103 

The Examiner rejected claims 1-10 and 30-39 (including independent claims 1, 30 and 39) 
under 35 U.S.C. §1 03(a) as allegedly being obvious over U.S. Patent No. 6,173,266 ("Marx") in 
view of U.S. Patent No. 7,266,181 ("Zirngibl"). 

The Assignee does not accede to the propriety of the combination of Marx and Zirngibl. 
However, the Assignee has not addressed the propriety of the combination because even if the cited 
combination were proper, the combination fails to disclose or suggest all of the features recited in 
each of the independent claims, as discussed below in connection with each of claims 1, 30 and 39. 

a. Overview of Embodiments 

Programmers of interactive speech applications are often faced with managing and preparing 
audio responses to catch events that occur during use of the speech application [See Tf 0002 of 
application as filed]. Such catch events may include user requests for help, non-input entries (in 
which no user response is received), and non-matching entries (in which the user response is not 
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understood) [Id.]. The process of coding the audio messages for each specific catch event can be 
tedious and time-consuming [Id.]. 

The specification evidences an appreciation that programmers of interactive speech 
applications would benefit from having the option to select a specific style to be used for responding 
to catch events [See Ifs 0003-0004 of application as filed]. FIG. 1, reproduced below, shows a style- 
selection menu 100 that may be presented to the programmer of an interactive speech application 
[See 1 0020 and FIG. 1 of application as filed]. Within the style-selection menu 100, style template 
120 allows the programmer to select a single style (i.e., "simple," "classic," or "modern") to 
correspond to a plurality of catch events (i.e., help, no input and non-match events) [Id.]. The style 
selected would correspond to text created to respond to a plurality of catch events, which could then 
be translated to code [See 1 0019 of application as filed.]. As a result, creation of text and/or code 
for each individual catch event becomes unnecessary, as one style maybe selected for all catch 
events, simplifying the programmer's task in managing catch events [See *|s 0018-0019 and FIG. 1 
of application as filed.]. 



Catch Event Style Selector 



100 

_2_ 



Select a style for your Help, Nomateh, and Noinput events." 
Style Template-- 120 Final action-'— 140 



©Simple— 125 
OCIassIc-— 130 
OModern-— 135 

l %|^-Numbercf retries: HTW 
Description 



-145 

ODisconnect 150 

OTransfer to Agent 155 



Simple Style: After any catch event (Help, Noinput, Nomateh), the application 
plays the prompt again. There are no contextual help messages (which makes 
a less usable application), but this allows the most rapid prototyping. With these 
settings, the system allows 2 retries, after which it will repeat. 



170" 



180 — [Rhlshl 



FIG. 1 
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The foregoing summary is provided to assist the Examiner in appreciating some aspects 

and/or applications of embodiments described in the present application. However, this summary 

may not apply to each of the independent claims, and the language of the independent claims may 

differ in material respects from the summary provided above. Thus, the Assignee respectfully 

requests that careful consideration be given to the language of each of the independent claims and 

that each be addressed on its own merits, without relying on the summary provided above. In this 

respect, the Assignee does not rely on the summary provided above to distinguish any of the claims 

over the prior art. Rather, the Assignee relies only upon the arguments provided below. 



b. Independent Claim 1 

As amended, claim 1 recites inter alia "presenting a style-selection menu for a plurality of 
catch styles that allows for selection of one or more of the catch styles, each catch style defining a 
system response to each of a plurality of catch events." The combination of Marx and Zirngibl does 
not teach or suggest this feature. 

The Office Action concedes that Marx does not teach style selection or catch styles, but 
alleges that Zirngibl teaches this feature. In particular, the Office Action states: 

Concerning independent claims 1, 30 and 39, the only elements not expressly disclosed by 
Marx et al are the concepts of "style" selection and "catch styles." Marx et al. discloses a 
plurality of default templates for error conditions when a user response is not understood, where 
an error condition is equivalent to a "catch", but omits the concept of "style" in describing a 
"catch" and a process of selection. However, it is known in the art of voice services to provide 
style sheets to create interactive voice services. Specifically, Zirngibl et al teaches a system and 
method for creation and automatic deployment of personalized dynamic and interactive 
voice services, where XML [sic] (extensible style sheet language) style sheets are provided to 
create voice services. An objective is to maximum [sic] an administrator's voice service building 
capability. (Column 11, lines 32 to 49) It would have been obvious to one having ordinary skill 
in the art to apply a concept of "style" to selection of "catch styles" as taught by Zirngibl et al. in a 
Dialogue Module selection method of Marx et al for a purpose of maximizing an administrator's 
voice service building capability. (Emphasis added.) 



As noted by the Examiner in the passage above, Zirngibl teaches the use of XSL style sheets 
in connection with voice service building. In particular, Zirngibl teaches converting report data into 
options by application of an XSL (extensible style sheet language) style sheet (col. 11, lines 39-41), 
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Such report data may comprise the status of a portfolio, and such options may comprise options to 
buy or sell stock (col. 10, lines 24-27). 

While the Office Action appears to assert that the XSL style sheets described in Zirngibl 
somehow relate to catch styles, XSL style sheets are merely used to convert an XML document 
from one schema to another (e.g., HTML) without having to write a program. They do not 
"[present] a style-selection menu for a plurality of catch styles that allows for selection of one or 
more of the catch styles," as recited in independent claim 1 or otherwise relate to catch styles. 
Further, although XML style sheets relate to style in that they may dictate the layout of a document, 
they are not menu-based and therefore do no relate to any sort of "style-selection menu," as recited 
in claim 1. 

Indeed, Zirngibl is completely silent with respect to the selection of one or more catch styles 
or a menu that allows the same. Catch styles are not described anywhere in Zirngibl, so that the 
selection of one or more catch styles is necessarily also not disclosed. 

In view of the foregoing, the combination of Marx and Zirngibl does not teach or suggest 
'"presenting a style-selection menu for a plurality of catch styles that allows for selection of one or 
more of the catch styles, each catch style defining a system response to each of a plurality of catch 
events," as recited in claim 1. For at least this reason, the rejection of claim 1 is improper and 
should be withdrawn. 

c. Independent Claim 30 

For reasons that may be appreciated from the discussion provided in connection with claim 
1, the combination of Marx and Zirngibl does not teach or suggest "a computer, the computer 
including an interface having a style-selection template for a plurality of catch styles that allows for 
selection of one of one or more of the catch styles, each catch style defining a system response to 
each of a plurality of catch events," as recited in claim 30. For at least this reason, the rejection of 
claim 30 is improper and should be withdrawn. 
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d. Independent Claim 39 

For reasons that may be appreciated from the discussion provided in connection with claim 
1, the combination of Marx and Zirngibl does not teach or suggest "presenting a style-selection 
menu for a plurality of catch styles that allows for selection of one or more of the catch styles, 
wherein each catch style defines a system response to each of a plurality of catch events," as recited 
in claim 39. For at least this reason, the rejection of claim 39 is improper and should be withdrawn. 

e. Dependent Claims 

Since each of the dependent claims depends from a base claim that is believed to be in 
condition for allowance (as discussed above), the Assignee believes that it is unnecessary at this 
time to argue the allowability of each of the dependent claims individually. However, the Assignee 
does not necessarily concur that the basis for the rejections of any of the dependent claims is proper. 
Therefore, the Assignee reserves the right to specifically address the patentability of the dependent 
claims in the future, if deemed necessary. 
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CONCLUSION 

In view of the foregoing amendments and remarks, this application should now be in 
condition for allowance. A notice to this effect is respectfully requested. If the Examiner believes, 
after this amendment, that the application is not in condition for allowance, the Examiner is 
requested to call the Assignee's representative at the telephone number indicated below to discuss 
any outstanding issues relating to the allowability of the application. 

The Assignee believes no fee is due with this response. However, if a fee is due, please 
charge our Deposit Account No. 23/2825 under Docket No. N0484.70570US00 from which the 
undersigned is authorized to draw. 



Dated: June 24, 2009 Respectfully submitted, 

Nuance Communications, Inc. 



By: 

Melissa A. Beede, Reg. No. 54,986 

Richard F. Giunta, Reg. No. 36,149 

Wolf, Greenfield & Sacks, P.C. 

Federal Reserve Plaza 

600 Atlantic Avenue 

Boston, Massachusetts 02210-2206 

Telephone: (617) 646-8000 
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